< Previous | Contents | Next >
SECTION 18.6 STREAMING STRATEGIES
One of the best approaches when beginning (to stream your productions) is to establish a relationship with a commercial streaming media provider. A good provider can guide you past firewalls, provide public addresses for everyone to view your stream, and provide no end of valuable guidance.
And it may not be as expensive as you think (costs vary based on considerations such as how many viewers you expect, how much web bandwidth you use each month, and so-on). Some services based on an advertising model will even host your stream free.
18.6.1 ON DEMAND OR LIVE STREAMING?
Not all ‘streaming’ is ‘live streaming.’ The difference is similar to i) watching a television program you previously recorded at a time convenient for you, or ii) watching a live event.
On demand streams are stored on a server (often supplied by an external service provider), ready to be transmitted whenever a viewer wishes. Live streams are available at the time they are broadcast, such as during a live concert or event.
ON DEMAND HOSTING
TriCaster permits you to record live productions to a local hard drive. The resulting files can be hosted on a network later, so viewers can connect whenever they like. If you have the resources available, you can host the video yourself – but if many people will likely want to view your production, you will likely avail yourself of a service to stream it on your behalf.
Ideally, ‘on demand’ streaming video begins to play on request after a few moments. (Letting the stream get a bit ahead of the client playback device is called ‘buffering’, and helps ensure smooth playback). This stands in contrast to other types of online video distribution which requires the viewer to completely download the video file before he can begin play. Given a sufficiently high speed connection between host and viewer, they may well be able to enjoy a seamless viewing experience without stuttering or other issues.
LIVE STREAMING
Live streaming is a growing international market, and one you may well wish to serve. This form of streaming is a somewhat more demanding implementation. Rather than record a file and deal with it later, live video is transmitted over the network (effectively in realtime, give or take a little ‘time in the pipe’ as it were.)
Delivering a good quality stream requires that you consider both your network connection capabilities and that of your viewers. As well, to ensure reliable delivery, you will ideally have some idea of the size of your audience. Nevertheless, for all cases, TriCaster gives you the tools to do the job.
Naturally, streaming video is highly compressed to reduce bandwidth demands and make it available to a wider group. TriCaster supports two popular and prolific encoding systems, Microsoft’s Windows Media® and RTMP (Adobe Flash®).
The decision as to which encoding format to use for your live stream is up to you or
– in some cases – your client. Here are some things to consider:
Some corporate and institutional network administrators opt to support one or another format exclusively. (Check with your IT department to find out if this affects your decision).
RTMP has a very wide installed user base, and seems poised to increase in proliferation in the foreseeable future.
RTMP works well across multiple platforms (PCs, Macs, Linux, etc.). Windows Media® is well represented, but perhaps not to the same degree.
Some sources report that the RTMP movies will have a larger file size and use greater bandwidth than Windows Media for a given stream quality. (This is hard to assess, and changes constantly as developers update their products).
Encoding applications for both types are updated with fair regularity, and when you choose the ‘latest, greatest’ encoding, your viewers may not all have the current player, requiring them to update.
BANDWIDTH CONSIDERATIONS
You’ll often hear the term ‘bitrate’ in connection with streaming video. This expression refers to data throughput per second (generally measured in Kilobits per second, or Kbps.)
You could think of this as being like water flowing through a hose. You control the ‘faucet’, because you get to choose the Stream Profile in TriCaster’s Stream Configuration panel. However, you don’t own the ‘hose’ – or at least, not the entire hose.
Once the stream leaves your immediate environment, even if you can supply good throughput locally, bandwidth may be constricted elsewhere along the transmission path. The level of Internet traffic can impose limits, but another major factor is the sort of connection your viewing audience may have.
Consider an example scenario:
Even though you know that most of your audience is going to connect to your program using (relatively slow) wireless devices, you use a very high outgoing bitrate – thinking that this will surely be enough to fill the need. The fact is, though, a high bitrate actually ensures their experience will be poor!
The client player tries to play the stream at the bitrate you specified, but (in this example) the wireless bottleneck impedes flow. It is as if you connected a fire hose on your end, giving them a suitable high capacity nozzle for their end – but in the last stage of flow, the stream must pass through a small garden hose. Sadly, the stream will be quite insufficient, and output from the ‘nozzle’ (the client player) will falter badly.
For reliable performance, try to ensure the potential upload bandwidth from your system to the net is around twice the bitrate you choose. You can broadcast at a rate closer to your actual ceiling, but reliable performance cherishes headroom.
Also consider the expected download abilities of your viewers. Ideally, a safety margin 1.5 times the stream’s bitrate is desirable. This may mean you need to consider using a lower resolution, or lower framerate for your stream – but doing so when required will generally deliver a smooth result, and is the wise course. (Nothing inclines viewers to turn away quicker than a stuttering, start and stop stream. See “Speed Tests” in Section 18.8.1 for some useful resources.)
Additionally, there are two primary streaming methods, known as Pull and Push. Choosing the best method for your needs is important. Let’s review each, and consider what is best for your needs.
PULL BY END USERS
Simply put, the Windows Media Encoder® in TriCaster allows your (networked) audience to connect directly to it, and it distributes the stream to them.
Connecting in this manner requires you to have a connection with sufficient bandwidth to deliver a stream to each individual user. For this reason, the simple Pull streaming method rarely works well for more than 1 or 2 viewers.
Advantages:
o When TriCaster is not behind a firewall or does not have a public IP address, this is a very simple way to let a few viewers watch your program stream.
Disadvantages:
o Requires either a public IP address or requires users to be on the same network. Facilities such as hotels or convention centers will usually not provide a public IP address. Even if they do, getting them to open holes in their firewall is next to impossible.
o If TriCaster is behind a router, your router must be configured to ‘port forward’.
o Requires significant bandwidth -- for example, with TriCaster connected to the Internet by a DSL or Cable Modem line, upload bandwidth is often less than 400kbits/second. Allowing for network overhead, at best a 320kbit steam can be accommodated. This bandwidth would be fully consumed by two viewers watching 160kbit streams, or a single viewer pulling a 170-320kbit stream. (Even a T1 digital line can only handle four simultaneous 300kbit streams).
A variation on the Pull method involves using an external streaming provider. At one time the only method for streaming using such a provider was to have the server ‘pull’ it from the encoder. Under this system the server did not receive the stream until the first user requested it. Then the server would connect to the
encoder, pull the stream to it, and finally begin re-distributing it to everyone requesting it. This method worked passably until firewalls became more common.
Advantages:
o Pull doesn’t waste bandwidth; no signal is being sent out to the server unless somebody wants to view it.
o If you lose your connection to the (provider side) server, the server will re-connect to your encoder automatically when Internet connection resumes.
o Providers typically have significant bandwidth, and are able to meet necessary requirements to deliver stutter-free, high quality streams to large numbers of viewers.
Disadvantages:
o Like the “Pull by End Users” method above, this requires a public IP address, preferably a “static IP address” (which does not change dynamically if you need to reconnect) as well as open ports for the connection to be established. These requirements are becoming increasingly difficult to meet (given common security measures).
PUSH TO PROVIDER
Windows Server2003® introduced “Push” technology. With this method, the encoder sends the stream to downstream servers. This allows the encoder to establish a connection to the server on a specified port. Once this connection is established, additional network ports may be opened as required (since the Encoder established the connection, not the server.)
Advantages:
o Easy to connect to the provider. There are no requirements for open ports on your local system, or public IP’s. In addition, firewalls do not get in the way.
Disadvantages:
o Live streams that have no viewers are still consuming bandwidth. From a provider point of view, it is possible that all of our bandwidth could be utilized with no viewers. However, that is more theoretical than practical.
o Some external streaming providers prefer to Pull streams, as re- connection can performed from their end automatically if necessary. But in many venues system administrators are very reluctant to configure their system with an open port to have your stream Pulled from.
18.6.3 STREAMING MEDIA PROVIDERS
Using a commercial streaming media provider (sometimes referred to as a Content Delivery Network, or simply ‘CDN’) bypasses otherwise high-bandwidth requirements for the encoding computer. When you have made arrangements for a streaming media provider to distribute your stream, the encoder only needs enough bandwidth to get a single a/v stream to the provider. All end users connect to the provider to view the stream.
Most streaming providers have access to massive bandwidth (and often, with very little notice, they can scale up your allotment to meet a temporary need.) Since your local bandwidth is really only used for uploading a single stream, you can send a high quality stream, secure in the knowledge that it will not degrade as soon as a second viewer attempts to see it.
Hint: A helpful way to find a good streaming service provider is to ask other TriCaster users for recommendations in NewTek’s online discussion forums.
If you’re still struggling with the differences between Push and Pull streaming methods, you can find lots of online resources (in addition to excellent information available in NewTek’s user forums!)
The popular web resource Wikipedia® hosts many articles on the subject, notably these two:
http://en.wikipedia.org/wiki/Push_technology http://en.wikipedia.org/wiki/Pull_technology
Microsoft even hosts an animation on the subject at:
www.microsoft.com/windows/windowsmedia/knowledgecenter/wminaction/stre aming_pushpull.asx
(Ignore the detailed discussion of configuring the encoder, and just enjoy the pretty pictures – your TriCaster makes that part easy for you!)